Why we built a wiki that ends in decisions

Every remote company we talked to in 2023 had the same shape of problem. The docs existed. The wiki existed, usually two of them. What did not exist was the moment where a page stopped being a draft and became the way things are done.

Decisions were happening, but in the worst places for them: a thread that scrolled away by lunch, a call that half the team slept through, a direct message between two people who then had to repeat it to everyone else. Ask anyone at a remote company why a process works the way it does and you will hear one of three answers: “It was decided on a call,” “Check the thread,” or “Ask Dana, she was there.” Dana, more often than not, has left.

Writing is the easy part

Our first version of Quill was a good editor and a page tree. It was fast, it had nice tables, and it imported from everything. Teams liked it and used it exactly like the tool they had left. The pages grew. Nobody trusted them.

We spent the spring of 2024 sitting in on the working lives of eleven remote teams, from a 14-person agency in Tucson to a 600-person logistics company outside Columbus. We watched how they looked for answers. Almost nobody searched the wiki first. They asked a person. When we asked why, the answer was nearly always the same: the page might be wrong, and I can’t tell.

That sentence changed the product. A wiki does not fail because people will not write. It fails because readers cannot tell what is true, and writers cannot tell when something they wrote has been overruled.

A discussion that has to end

The turn came when we added one small thing to a page: a discussion that had to end. Not comments, which never end, but a thread with a closing move. Somebody opens it with a question and a close date. People weigh in when they are online, in their own morning. When the date arrives, the person who opened it writes the decision at the bottom, in a sentence or two.

The decision pins itself to the page it changed, and it lands in a log. That log turned out to be the most-read thing in every workspace we tested it in, ahead of the handbook and ahead of the onboarding checklist.

Why the close date matters

We tried discussions without a close date first. They behaved like every comment thread ever built: they trailed off. Adding a date (three working days by default) did something we did not expect. It made people answer. A thread that will close on Thursday is a thread you reply to on Tuesday.

Pages with a name and a date on them

Once decisions had a home, the second half of the problem became obvious. A decision changes a page. If nobody owns the page, nobody updates it, and the page and the decision drift apart.

So every page in Quill got an owner and a verification date. Every ninety days, the owner gets one reminder: is this still true? They click verify, or they fix it, or they hand it to someone else. A page that lapses says so at the top in plain words, and search ranks it below the pages that are current.

• Pages got owners, because a decision needs someone to write it into the page.
• Meetings got shorter, because the arguments had already happened in writing.
• New hires stopped asking where things were, because the decision log was the map.

What we are not building

We get asked for a lot of things: project boards, a chat app, a CRM-shaped page type. We say no to almost all of it. There are excellent tools for those jobs, and Quill connects to most of them. What there was not, when we started, was a place where writing turns into deciding.

The hardest part of remote work is not talking. It is deciding, and then remembering what you decided.

That is the whole product, really. A place to write things down, a way to argue about them without a meeting, and a record of what was decided. We think most remote companies need exactly that, and they need it to be quiet, fast and trustworthy more than they need it to be clever.

Today 1,140 teams run their handbook, their on-call pages and their decisions on Quill, from clinics in North Carolina to a game studio in Pittsburgh. We are a remote company too, spread from Portland to Brooklyn, and every decision in this post is in our own log, with a date on it.